A computer may communicate with remote devices such as residential gateways, network attached storage devices, routers, print servers, media servers, etc. Such devices typically require configuration, but they typically do not have a physical interface (e.g., monitor, keyboard, mouse) to facilitate such configuration. Accordingly, such devices may be referred to as “headless” devices. To configure such a headless device, the computer may be communicatively coupled to the device, typically via a local-area network (LAN), so that the user is enabled to communicate with the device. Thus, from a user interface presented at the computer, the user can typically access and modify configuration information on the remote device. Such configuration information may include the name of the device or parameter information such as an Internet Protocol (IP) address associated with the device, for example.
Typically, configuration information is sent to the computer in the form of an HTML file. A browser on the computer renders the web page from the HTML file, and thereby presents the information to the user in a desired format (e.g., layout and appearance) and in a language that the user is expected to understand (e.g., English). The web page serves as a remote user interface, i.e., an interface to the remote device, via which the user may, for example, remotely change the configuration information associated with the device.
FIG. 1 is a block diagram of an example embodiment of a prior art system 200 for providing a remote user interface. The system 200 may include one or more computers 210, which may be desktop computers, laptop computers, etc., and one or more network devices 230, which may be headless devices such as described above.
The device(s) 230 may be communicatively coupled to the computer 210 via a network 220, which may be a LAN or a wide-area network (WAN) such as the Internet, for example. The device(s) 230 may be in communication with the computer 210 through a direct connection with the computer 210, with or without being communicatively coupled to the computer 210 via the network.
The computer 210 may be used to provide the user with a user interface via which, for example, the user can remotely configure the device 230. The computer 210 may include a physical user interface, such as a display and mouse or keyboard, for example, and browser software that may be executed on the computer 210.
The device 230 may have stored thereon a file 232 that enables a browser to render a web page. The file 232 may be in a mark-up language, such as HTML, for example. The web page may, for example, enable a user of the computer 210 to access and modify configuration information on the remote device 230. To configure the device 230, the user of the computer 210 launches the browser on the computer 210 and connects, via the network 220, to the device 230. The computer retrieves the HTML file from the device 230 and renders the web page defined by the HTML file.
The HTML file 232 includes one or more predefined or “hard-coded” parameter values 234. The HTML file 232 also includes HTML code, scripts, images, objects, and the like (not shown), that define the layout and appearance or “skin” 236 of the web page. The HTML file 232 may include such code, scripts, images, objects, etc., explicitly, or it may include references to other files that include such code, scripts, images, objects, etc. When the web page is rendered, the hard-coded parameter values 234 appear within the web page in accordance with the skin 236.
An example of such an HTML file 310 is depicted in FIG. 2. As shown, a first parameter 311 may be defined as having a value of “IP address: 217.160.219.11.” Similarly, a second parameter 312 may be defined as having a value of “subnet: 255.255.255.0.” A third parameter 313 may be defined as having a value of “gateway: 217.160.219.1.” A fourth parameter 314 may be defined as having a value of “name: device1.” When the web page is rendered, these values appear within the web page in accordance with the skin.
Such an HTML file may be generated by the device's web browser, either by running an ISAPI plug-in, CGI script, or an ASP page. Usually, the code that generates such an HTML file is produced by one or more developers or programmers of the device. To produce the HTML file, the developers must access configuration data on the device such as, for example, values associated with certain parameters, such as an IP address, for example.
The developers also need to know the desired layout and appearance, or “skin,” of the web page presented to the user via a display on the remote computer. In some instances, the device manufacturer or distributor may want the rendered web page to have different skins under different circumstances. Further, the configuration software may be sold to different vendors, each of which may want the ability to reskin so that the software takes on the specific look and feel they want.
Additionally, the developers need to know the geographic location of intended users so that any displays will be in a language understood by the users. For example, if the device is intended for use in a certain country, then the rendered configuration page should be in a language understood in that country. Typically, all of these factors will be accounted for in the logic or coding provided in the application or service responsible for generating the HTML file before the device is shipped to the end-user. Therefore, all of the information related to these factors typically must be known by the developers when developing the default HTML file.
None of the developers, however, may have all of the information because, for example, there may be one developer involved with developing the skin for the configuration page and a separate developer involved with the parameter data for the device itself. There may be a third developer involved in localizing the web page. It would e desirable, therefore, if methodologies were available to provide remote user interfaces without the need for hard-coding parameter values.